Description

This PR extends the reusable get-requirements workflow with shadow-only standard/locales CI decisions.

It adds these outputs:

• locales_only
• locales_validation_needed
• standard_ci_needed
• requirements_enforced

It also adds a GITHUB_STEP_SUMMARY section that reports changed-file classification, existing E2E decisions, standard/locales decisions, enforcement state, and the future standard-CI skip mapping.

No standard CI jobs consume these outputs yet, so CI execution remains unchanged. This is only to collect validation data before enforcement.

Reviewer note: the new shadow step defines its own ALL_CHANGES_COUNT environment binding from the existing paths-filter output. The E2E step already reads the same output separately; this is intentional because step-level env bindings are scoped to each step.

Changelog

CHANGELOG entry: null

Related issues

Refs: MCWP-440

Manual testing steps

N/A - workflow-only change. Local validation:

• ruby -e "require 'yaml'; YAML.load_file('.github/workflows/get-requirements.yml')"
• actionlint -color -config-file .github/actionlint.yaml .github/workflows/get-requirements.yml
• git diff --check

Screenshots/Recordings

Before

N/A

After

N/A

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.